Summary by CodeRabbit

• Chores
  • Updated ownership settings for select package-related files.
  • Improved release workflow reliability by making Corepack installation more robust and allowing binary build jobs to continue running even if one matrix entry fails.

The v1.3.0 release run failed on the build-binaries (win32-x64) leg at the Install pnpm step:
npm error EEXIST: file already exists … C:\npm\prefix\yarn. The GitHub Windows runner already ships corepack's yarn shim, so npm install -g corepack@0.35.0 collides. With default fail-fast: true, this also canceled the otherwise-healthy linux/darwin legs.

• Add --force to the corepack install in all three release.yml jobs (overwrites the pre-existing shim; no-op on Linux/macOS).
• Add fail-fast: false to the build-binaries matrix so one platform failure no longer cancels the others (diagnostics only — create-release still requires all four legs).
  No Shield logic, package output, or runtime change. Windows-runner packaging fix only.

QA Proof

• Root cause from the failed run: EEXIST C:\npm\prefix\yarn on the win32 Install pnpm step
• The rest of the run was healthy: security-audit passed, harden-runner egress clean (expected hosts only), Socket "nothing to report", darwin attestations + artifacts produced.
• Cannot be E2E-tested locally (GitHub-hosted Windows runner) — see below.

What Needs to Be Verified on the Re-tag Release Run

• build-binaries (win32-x64) passes the Install pnpm step and builds shield-windows-x64.exe
• All four legs build (with fail-fast: false, all run regardless)
• create-release produces the GitHub release with all binaries + .sha256
• (then resume the full hardened-release verification runbook)

QA Team Notification

• N/A pre-merge — validation is the re-tagged v1.3.0 release run (binary track needs no approval; npm publish still gated on production environment approval)